An enterprise may employ a variety of software applications and/or services in the course of its operations. These software applications and/or services may be used to accomplish a variety of enterprise tasks and may be used in conjunction with one or more back-end systems, e.g., servers, databases, etc. The back-end systems may store enterprise data such as, for example, business objects and other business data, as well as logic for manipulating the enterprise data, such as transactional logic or other business logic. In order to accomplish the enterprise operations, the software applications and/or services may need to access the stored enterprise data from a database of the back-end system. The back-end system may employ, for example, the SAP HANA Database, which is a column-oriented, in-memory database available from SAP AG, Walldorf, Germany. The database may communicate with an application through a database management system (DBMS). The database may also be in communication with a plurality of different storage media exhibiting different characteristics (e.g., speed, cost, reliability, energy consumption).
The enterprise data may be stored in a database with a data aging functionality that stores data in a specific partition of the database based on an “aging date” associated with the data and a corresponding partition date (or partition date range) associated with the partition. The database may also include other data segregation functionalities such as for storing the enterprise data according to a current status (e.g., pending or closed) of the data, and/or any other values that can be used to segregate the data into separate partitions of the database. For example, data that has a recent aging date (e.g., less than a year) and/or has an “aging value” of “pending”, e.g., business-relevant (or “current”) data, may be stored in faster, more expensive storage media that may be quickly accessed, and data that has an older aging date (e.g., more than a year) or has an aging value of “closed”, e.g., non-relevant (or “historical”) data, may be stored in slower, less expensive storage media. Accordingly, the enterprise data may be stored in separate partitions of a database according to a storage hierarchy so that it may be easily accessed. The aging date/value of a data record may be assigned based on the logic of rules (e.g., business rules) for manipulating a software object (e.g., business object) that refers to the data record.
The purpose of data aging is to reduce the memory footprint of software applications that access the age-segregated data in order to reduce the system load, for example, by storing historical transactional data in slower/cheaper partitions of the database in an online transaction processing (OLTP) environment. Although the data may be stored redundantly at different levels (e.g., partitions) of a storage hierarchy (e.g., database system), the cost of storing the data may be optimized by storing only the most current data in the top level(s) of the storage hierarchy. After an aging date/value has been assigned to particular software object data (e.g., a data record) and an appropriate storage location (e.g., database partition) has been determined, the data may be appropriately queried/accessed. However, given the multiple aging dates/values of the stored data, it may be difficult to determine how to optimally access data from several different storage levels, so that data queries do not necessarily load or even process data having an older aging date/value if such data would not contribute to the result set of the query.
Rules (e.g., business rules) may be applied to the data in order to ensure that all data records that are related to each other, from a holistic perspective of the rules, may only be stored within the same (and/or a higher level for newer data) of the storage hierarchy. Software objects comprising related pieces of data may be stored in the database across different data structures (e.g., tables). In this way, tables of records that are linked together by “relationships” may be stored separately while still allowing a user to make complex queries against the database in an efficient manner. Therefore, a query for data associated with a same software object (as manipulated by the rules) will return the full result sets from a rules perspective. Structured Query Language (SQL) is a standardized language for creating and operating on such “relational” databases. However, how far into the historical data a query should reach may not always be clear before the query is executed.